The present technique relates to methods and apparatus for handling processor exceptions.
During the normal flow of execution through a program executed by a processor, the processor's program counter increases sequentially through the program address space, with branch instructions causing branching of program flow to other addresses, and other instructions causing links to subroutines followed by returns from those subroutines. Processor exceptions occur when this flow of execution defined by the program instructions is diverted, to allow the processor to handle events generated by internal or external sources. These events can be of different types or categories, with examples of such event types including: externally generated interrupts, for example by a peripheral device (often referred to by the acronym “IRQ”, for “interrupt request”), an attempt by the processor to execute an undefined instruction, or a requirement to access a privileged operating system function. When an exception occurs, the program flow is changed so as to deal with the exception, while still preserving the previous processor status, so that execution of the program code that was running when the exception occurred can resume when the appropriate exception routine has completed.
In some processor architectures an exception “vector table” is provided which contains instructions known as vectors, one such vector being provided for each type of exception. In response to an exception the processor fetches the relevant instruction in the vector table (appropriate to that exception type) and executes it. In many instances, the instruction in the vector table will in fact be a branch instruction diverting program flow to a so-called “handler” (a set of instructions for execution) to service the exception. The address in the vector table relating to an exception type may be referred to as an “exception address” relating to that exception type.
Some types of exception can have multiple potential causes. For example IRQs can be initiated by a range of peripheral devices, so that a first or early action of the handler is to detect the source or cause of the interrupt and then branch to a further, more specific, handler to service that particular IRQ. This can mean that for IRQs, and potentially some other exception types, the processor can be forced to divert program flow to a new address three times before it starts to execute the final (specific) event handler: once for the vector fetch, once for the first (generic) handler for that event type, and once for the specific handler.
In the case of a pipelined processor, each of these diversions of program flow can involve flushing (clearing) the processor pipeline, which incurs a time penalty in the form of a delay while the pipeline is refilled. For example, in a pipeline using (say) three or four instruction fetch stages, empirical tests have found that this issue can account for a significant proportion of the overall latency relating to interrupt handling. But as well as potentially causing additional latency, the use of multiple stages of flushing and reloading the pipeline can adversely affect power consumption of the processor, because the processor has to flush instructions that it has needlessly fetched.